[アップデート]Amazon GuardDutyのEC2ランタイム保護がGAしたので詳細な動作確認してみた

こんにちは、臼田です。

みなさん、EC2の脅威検出してますか？(挨拶

今回はついに、待望の、待ちに待ったAmazon GuardDutyのEC2 Runtime Monitoring機能がGAしたのでこれを紹介します！

Amazon GuardDuty EC2 Runtime Monitoring is now generally available | AWS News Blog

ちなみにこの元記事にある以下の画像、最新のGuardDutyイケてる感を感じるいい画像じゃないですか？

概要

Amazon GuardDutyは脅威検出のサービスで、AWS環境上の様々な脅威を検出できます。例えばEC2でコインマイニングされているとか、IAMが不正に利用されているとか、S3のデータが漏洩しているとか、発生している様々な脅威に反応してくれます。

これらの検出はCloudTrailログ/VPCフローログ/DNSログなど様々なAWSが収集できるログを活用して見つけますが、EC2やECS/EKSなどのコンピューティングリソース上(実行環境)での動作はこれらのログには出力されません。しかし脅威は実行環境上でも発生します。なので最近ECS/EKS環境では先立って実行環境の脅威を検出するために、エージェントを活用してRuntime Monitoringの機能が動作するようになっています。これで実行環境上の脅威検出もGuardDutyが担当できるようになりました。

去年のre:InventにてEC2のRuntime Monitoringのプレビューがリリースされ、今回これがGAしました。プレビュー時の内容は下記にありますのでご確認ください。

GAで変わったこと

料金が安くなった

GAに際して、かどうかはわかりませんが料金が安くなりました！なんと嬉しい！

上記の記事にはvCPU あたり2.00 ドルとありますが、現在の料金ページではvCPU あたり1.50 ドルになっていました！

なお、Runtime Monitoringのログ収集にはVPC Endpointを利用しますが、この利用は無料であることと、そのためのネットワーク帯域も無料であることが記載されています。また、Runtime Monitoringの対象となるEC2のVPCフローログ分のGuardDuty利用料も無料です。2重で請求されることがないと明記されています。

EC2のエージェント自動管理に対応した

プレビューの段階では、GuardDutyのエージェントをEC2にインストールのと、VPCエンドポイントを作成するためには手動で対応する必要がありました。

GAではこういったGuardDutyで管理するための手間がなくなりました！ポチッと機能をオンにしておけば、自動でGuardDutyの管理下になります。すばらっ！

今回はこの新しく対応した自動管理の仕組みを使って、後ほどやっていきたいと思います。

この機能は誰が使うべきなの？

ここまで説明を聞いて、「良さそうな機能な気がするけど、他のセキュリティ対策と被らない？」「GuardDutyのオプションいっぱいあるけどこれも使った方が良いの？」と思う方もいるかもしれません。なので、この機能を使うべきかどうかの判断方法を伝授します。

まず、今回のAmazon GuardDutyのRuntime Monitoringの機能は実行環境の脅威を検出するものです。実行環境での脅威は、不正なプログラム(マルウェア)が実行されたり、不審な通信(マイニングとか不正なサーバーへの通信とか)が発生したりすることで、主に外部に公開しているサーバーが特にリスクが高いものです。

こういった脅威に対してEC2でアンチマルウェアなどのセキュリティサービスを使っている場合には重複しますので、GuardDutyのRuntime Monitoringの利用は不要です。GuardDutyではあくまで検出のみなので、機能としても脅威を即時ブロックできるアンチマルウェアのサービスを活用いただくほうがいいです。

一方で、GuardDutyはポチッとしておくと、すべてのEC2に対してこの機能を発揮するため、ヌケモレなく対策していく場面では非常に優秀です。そして何よりコストが安いですから、すべてのEC2にアンチマルウェアを導入していなくても、最低限の対策としてGuardDutyのRuntime Monitoringを活用する、という考え方ができます。

実行環境の脅威は特に外部(インターネット)と接する場合にリスクが高くなりますので、外部と接するEC2がある環境では実行環境のモニタリングや保護を行うべきで、自社にとって重要なシステムやサーバーであれば即時ブロックの効果が期待できるアンチマルウェアのサービスを、重要ではなくてもそういうEC2があるならGuardDutyのRuntime Monitoringを活用しましょう。

ちなみに本番環境はともかく検証環境はやらなくてもいいよね？って思った方、検証環境のほうが一般的に利用者のセキュリティ意識が低く、軽い気持ちでEC2のパブリックアクセスを許可していたりすることは非常によくあるので、ガバナンス的にもすべてのAWS環境でRuntime Monitoringを活用していくことがいいでしょう。インターネットに接している限り本番環境と検証環境でリスクの大きさは変わらない上、やられた後に待ち受けるコインマイニングとかはどちらでも変わらないでしょう。

やってみた

今回はGuardDutyは有効化されている状態で、Runtime Monitoringを有効化するところからやってみます。ざっくりやることは以下の通りです。

• Runtime Monitoringの有効化
• EC2の作成
• 自動で動作する諸々の確認
• 脅威の検出
• EC2の削除

EC2 Runtime Monitoringの有効化手順はこちらのユーザーガイドにあるのですが、あまりたいしたことは書いてありません。順に見ていきましょう。

Runtime Monitoringの有効化

まずGuardDutyのオプションであるRuntime Monitoringを有効化していきましょう。GuardDutyのマネジメントコンソールから「ランタイムモニタリング」を開いて「有効にする」を押すだけです。

確認のポップアップが出ますので「確認」を押します。

ランタイムモニタリングが有効化されました。しかしこのままではランタイムモニタリングのエージェントは自動でセットアップされません。というわけでEC2の自動エージェント設定を有効にします。

これも確認が出るので「確認」を押します。

無事有効化され、ステータスでもその状態が確認できました。

ちなみに、GuardDutyのRuntime MonitoringではVPC Endpointを利用して情報を収集するのですが、現時点ではこれは作成されていません。

これでEC2のRuntime Monitoringを利用する準備が完了しました。後はやることはありません。ちょー簡単に利用できますね！すばらっ！

EC2の作成

では動作を確認するためにEC2を作成していきます。今回はGuardDutyで管理したいEC2が1台もない状態で始めています。もし既存で存在しているならこの作業は不要です。

なお、サポートされるOSはこの前提条件のドキュメントに書いてあり現状では以下のとおりです。

• OS種別
  • Amazon Linux 2
  • Amazon Linux 2023
• カーネルバージョン
  • 5.4
  • 5.10
  • 5.15
  • 6.1
• CPUアーキテクチャ
  • x64 (AMD64)
  • Graviton (ARM64)

ちなみに、前提条件のドキュメントにはエージェントのCPUとメモリの制限についても記載があり、最大CPU制限は合計vCPUコアの10% 、メモリは以下の通りとなっています。

Amazon EC2 インスタンスのメモリ	GuardDuty エージェントの最大メモリ
8GB未満	128MB
32GB未満	256MB
32GB以上	1GB

今回は対象OSであるAmazon Linux 2023を作成しました。

GuardDutyのランタイムモニタリング画面では「ランタイムカバレッジ」でGuardDutyの管理下にあるインスタンスの数が確認できます。以下のように、管理下に置かれたことが確認できました。EC2を起動するだけで自動で管理されました。簡単ですね。

自動で動作する諸々の確認

さて、利用開始は非常に簡単であることがわかりましたね。ではその内側はどうなっているのでしょうか？もう少し紐解いてみましょう。

まずはエージェントから収集するデータを通信するためのVPC Endpointを確認しに行ってみましょう。すると、先ほど確認したときにはなかったVPC Endpointが該当VPCに作成されました。

VPC EndpointはすべてのVPCに自動的に作成されるわけではなく、このドキュメントにある通り以下の条件で作成されます。

• VPC内に終了またはシャットダウンされたインスタンス状態にないLinux EC2インスタンスが少なくとも1つある

つまり、動いているLinux EC2があれば作成されるということですね。

自動で作成してくれるので、ヌケモレなくGuardDutyでカバーしていくことができますね。ちなみに、下記ブログのように共有VPCも対応しているため、共有VPCでも自動作成されます。

続いてエージェントのセットアップを確認します。エージェントはAWS Systems Managerのステートマネージャーの機能によってセットアップされます。ステートマネージャーを見に行くと、以下のようにそれが自動で設定されていることが確認できます。

実行される内容自体はSSMドキュメントとして定義されていて、AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPluginという名前です。

実行した内容を確認してみましょう。上記の設定の詳細画面を開き「実行履歴」タブで該当のEC2に対するセットアップの実行履歴が確認できます。

Outputを開きます。

SSMドキュメントに記載されているステップごとのOutputがありますのでこれを開いてみていきます。

1つ目のステップはcheckProvisioningEligibilityというステップで、セットアップするかの判断を行うステップです。ログは以下の通りでした。

Failed to get instance tags from instance metadata or no GuardDutyManaged present in tag keys. Assuming no exclusion tag present.
Will provision GuardDuty agent.

GuardDutyManagedタグがないのでセットアップ対象と判断したということですね。Runtime Monitoringの対象外とする場合にはタグを設定していく必要があり、設定していなければ対象となるといことですね。ちなみに対象外にしたい場合にはEC2作成時にタグを設定しておかないとエージェントのインストールがされてしまいますので気をつけましょう。それはこのあたりのドキュメントとかに書いてあります。

2つ目のステップはconfigurePackageで実際にエージェントをインストールします。以下のようなログになっていました。

Initiating AmazonGuardDuty-RuntimeMonitoringSsmPlugin 1.1.0 install
Plugin aws:runShellScript ResultStatus Success
install output: Running sh install.sh
Verifying...                          ########################################
Preparing...                          ########################################
Updating / installing...
amazon-guardduty-agent-1.1-0          ########################################
Amazon GuardDuty agent installed successfully.

Successfully installed AmazonGuardDuty-RuntimeMonitoringSsmPlugin 1.1.0

無事インストールされているログが確認できました。

色々確認しましたが、これらが裏側で自動で実行されているので、ポチッとするだけで簡単にEC2を管理していける事がわかりましたね。

脅威の検出

ではRuntime Monitoringの効果を確認していきます。実際に脅威を発生させてみます。

今回はコインマイニングのスクリプトを仕込んでみます。詳細は割愛します。

はい、実行しました。

数分後以下のようにGuardDutyでコインマイニングが検出されました！

色々検出がありますが、一連の動作が様々なタイプで検出されています。特徴的なのは、従来からあるEC2タイプの検出(エージェントではない検出)よりも3分早くRuntime側の検出があがりました。もしかしたらRuntimeでの検出の方が早い！？これは未検証なので実際どうかは不明です。

検出内容としては、Impact:Runtime/CryptoMinerExecutedが実際のマイニングが実行されていることを検出していて、他はマイニングの通信をしている検出です。従来の検出だとマイナーが実行されているかどうか分からなかったので、より解像度があがっていますね。

検出結果の中身も解像度が上がっています。従来は通信しか見ていなかったですが、実行環境上でエージェントが動いているので、プロセスレベルで詳細がわかります。以下のように、ファイルやパスの情報なども取れます。

さらに、プロセスツリーもわかります。どの親プロセスから実行されているかわかるため、誰がどのように実行したか読み取れます。

従来は検出しても、別途マルウェアスキャンをしたり、場合によっては中身を確認する必要がありましたが、その手間がだいぶ減りますね。

しばらくすると遅れてEBSのスキャン結果もあがってきました。これは今回の設定と関係なく、GuardDutyのMalware Protectionの機能を有効化していたためです。こちらも便利なので使いましょう。実際に実行されたファイル以外に、その過程で生まれているgzファイルもちゃんと検出できていますね。これも有用です。

一通り確認が終わりましたので、検出結果をアーカイブします。ちなみに最近まとめてアーカイブする際にフィードバックもまとめて送れるようになりました。

まとめてアーカイブすると以下のようにフィードバックボタンが現れます。

フィードバックの理由も送れます。テストで検出させた場合には「ペンテスト (GuardDuty がレッドチームアクティビティを正常に検出)」を選択するのがいいですね。GuardDutyをこれからも快適に使っていくために、ガンガンフィードバックしましょう。

EC2の削除

確認が済んだのでEC2を削除します。

なお、EC2を削除しても、一度作成されたVPC Endpointは削除されませんので注意してください。お金はかかりませんが、要らなくなったら消しましょう。

まとめ

GuardDutyでEC2のRuntime Monitoringが正式にサポートされました。

すべてのEC2を簡単にカバーして詳細なインサイトを得られる機能なので、ガンガン使っていきましょう！